Protokoły sieciowe

Protokół internetowy, IP

• Protokół komunikacyjny warstwy sieciowej modelu OSI (warstwy internetu w modelu TCP/IP). Protokół internetowy to zbiór ścisłych reguł i kroków postępowania, które są automatycznie wykonywane przez urządzenia w celu nawiązania łączności i wymiany danych. Używany powszechnie w Internecie i lokalnych sieciach komputerowych. Dane w sieciach IP są wysyłane w formie bloków określanych mianem pakietów. W przypadku protokołu IP, przed rozpoczęciem transmisji nie jest zestawiana wirtualna sesja komunikacyjna pomiędzy dwoma hostami, które nie komunikowały się ze sobą wcześniej. Protokół IP jest protokołem zawodnym – nie gwarantuje, że pakiety dotrą do adresata, nie zostaną pofragmentowane, czy też zdublowane, a ponadto mogą dotrzeć do odbiorcy w innej kolejności niż zostały nadane. Niezawodność transmisji danych jest zapewniana przez protokoły warstw wyższych (np. protokół sterowania transmisją), znajdujących się w hierarchii powyżej warstwy sieciowej. 

Protokół odwzorowania adresów 

• Opisaliśmy już schemat adresowania TCP/IP, w którym każdy komputer ma przypisany 32-bitowy adres jednoznacznie identyfikujący go w sieci. Jednak dwie maszyny mogą się komunikować tylko wtedy kiedy znają nawzajem swoje adresy fizyczne. Zachodzi więc potrzeba przekształcenia adresu IP na adres fizyczny tak aby informacja mogła być poprawnie przesyłana. Problem ten przedstawimy na przykładzie sieci ethernet, w której mamy do czynienia z długim 48-bitowym adresem fizycznym przypisanym w trakcie procesu produkcyjnego urządzeń sieciowych. W efekcie podczas wymiany karty sieciowej w komputerze, zmienia się adres fizyczny maszyny. Ponadto nie ma sposobu na zakodowanie 48-bitowego adresu ethernetowego w 32-bitowym adresie IP. Przekształcenia adresu IP na adres fizyczny dokonuje protokół odwzorowania adresów ARP (Address Resolution Protocol), który zapewnia dynamiczne odwzorowanie i nie wymaga przechowywania tablicy przekształcania adresowego. 

Wady działań ARP

• Jest zbyt kosztowny aby go używać za każdym razem gdy jakaś maszyna chce przesłać pakiet do innej: przy rozgłaszaniu każda maszyna w sieci musi taki pakiet przetworzyć. 
• W celu zredukowania kosztów komunikacji komputery używające protokołu ARP przechowują w pamięci podręcznej ostatnio uzyskane powiązania adresu IP z adresem fizycznym, w związku z tym nie muszą ciągle korzystać z protokołu ARP. 
• Ponadto komputer A wysyłając prośbę o adres fizyczny komputera C od razu dowiązuje informację o swoim adresie fizycznym. Ponieważ prośba ta dociera do wszystkich komputerów w sieci, mogą one umieścić w swoich pamięciach podręcznych informację o adresie fizycznym komputera 
• Jeśli w komputerze zostanie zmieniony adres fizyczny (np. w wyniku zmiany karty sieciowej), to może on bez zapytania o jego adres fizyczny rozgłosić go do innych komputerów, tak aby uaktualniły informacje w swoich pamięciach podręcznych. 
  

Protokół odwrotnego odwzorowania adresów 

• Maszyna może uzyskać adres fizyczny innego komputera, znając jego adres IP. Adres IP jest zwykle przechowywany w pamięci zewnętrznej komputera, skąd jest pobierany w trakcie ładowania systemu operacyjnego. Nasuwa się więc pytanie: jak maszyna nie wyposażona w dysk twardy określa swój adres IP? Odpowiedź: w sposób przypominający uzyskiwanie adresu fizycznego. protokół odwrotnego odwzorowania adresów RARP (Reverse Address Resolution Protocol) umożliwia uzyskiwanie adresu IP na podstawie znajomości własnego adresu fizycznego (pobranego z interfejsu sieciowego). Komputery bez dysku twardego pobierają adres IP z maszyny uprawnionej do świadczenia usług RARP, po przesłaniu zapytania z własnym adresem fizycznym.

Kapsułkowanie

• Nazywamy rozwiązanie, w którym jeden datagram przenoszony jest przez jedną ramkę sieciową. Datagram zachowuje się wówczas jak każdy inny komunikat przesyłany z jednej maszyny do innej, tzn. podróżuje w części ramki sieciowej przeznaczonej na dane. 
  

Fragmentacja

• W tym przypadku cały datagram mieści się w jednej ramce fizycznej. Nie zawsze jednak jest to możliwe. Dzieje się tak dlatego, że datagram może przemieszczać się przez różne sieci fizyczne. Każda z nich ma ustaloną górną granicę ilości danych, które mogą być przesłane w jednej ramce. Ten parametr sieci nosi nazwę maksymalnej jednostki transmisyjnej danej sieci (ang. Maximum Transfer Unit - MTU). Ograniczenie wielkości datagramów, tak aby pasowały do najmniejszego MTU, byłoby nieefektywne w przypadku przechodzenia przez sieci, które mogą przenosić większe ramki. Jeśli datagram nie mieści się w ramce fizycznej jest dzielony na mniejsze kawałki zwane fragmentami, a proces ten nazywa się fragmentacją. Gdy takie pofragmentowane datagramy dotrą do odbiorcy podlegają procesowi odwrotnemu czyli defragmentacji. 

Kontrola fragmentacji

• Pole IDENTYFIKACJA (16-bitowe) zawiera liczbę całkowitą jednoznacznie identyfikującą datagram. Identyfikator jest niezbędny, gdyż zapobiega wymieszaniu się fragmentów pochodzących od różnych datagramów - wszystkie kawałki będące częściami tego samego datagramu posiadają ten sam identyfikator. 
• Pole ZNACZNIKI (3-bitowe) służy do kontroli fragmentacji. Pierwszy z trzech bitów jest nie używany, nadanie drugiemu wartości 1 oznacza bezwzględny zakaz fragmentacji. Jeśli datagram nie może być przesłany w całości, zostaje odrzucony i sygnalizowany jest błąd. Ostatni z bitów ZNACZNIKÓW umożliwia identyfikację ostatniego kawałka datagramu - ma w nim wartość 0, w pozostałych przypadkach 1. 
• Pole PRZESUNIĘCIE FRAGMENTU (13-bitowe) zawiera informację, w którym miejscu datagramu umiejscowione są informacje przesyłane w tym kawałku. Jest ono mierzone w jednostkach 64-bajtowych. Umożliwia to poprawne scalenie datagramu - nie istnieje nic w rodzaju kolejnego numeru kawałka w datagramie. 

Protokół ICMP 

• powstał aby umożliwić routerom oznajmianie o błędach oraz udostępnianie informacji o niespodziewanych sytuacjach. Chociaż protokół ICMP powstał, aby umożliwić routerom wysyłanie komunikatów to każda maszyna może wysyłać komunikaty ICMP do dowolnej innej. Protokół ICMP jest traktowany jako wymagana część IP i musi być realizowany przez każdą implementację IP. Z technicznego punktu widzenia ICMP jest mechanizmem powiadamiania o błędach. Gdy datagram powoduje błąd, ICMP może jedynie powiadomić pierwotnego nadawcę o przyczynie. Nadawca musi otrzymaną informację przekazać danemu programowi użytkownika, albo podjąć inne działanie mające na celu uporanie się z tym problemem. 

Każdy komunikat ICMP ma własny format, ale wszystkie zaczynają się trzema takimi samymi polami: 

• 8-bitowe pole TYP komunikatu identyfikuje komunikat 
• 8-bitowe pole KOD daje dalsze informacje na temat rodzaju komunikatu, 
• Pole SUMA KONTROLNA (obliczane podobnie jak suma IP, ale suma kontrolna ICMP odnosi się tylko do komunikatu ICMP). 

Dostarczanie komunikatów ICMP 

• Komunikaty ICMP wymagają dwóch poziomów kapsułkowania.Każdy komunikat ICMP podróżuje przez intersieć w części datagramu IP przeznaczonej na dane, a ten jak wiemy przemieszcza się przez sieć fizyczną w części dla danych ramki. Chociaż komunikaty ICMP są kapsułkowane i przenoszone przy użyciu IP, nie są protokołem wyższego rzędu lecz wymaganą częścią IP. 
  

Określanie ostatecznego adresata 

• System operacyjny większości komputerów zapewnia wielozadaniowość. Omówiony mechanizm adresowania i przesyłania datagramów nie rozróżnia użytkowników ani programów użytkowych, do których jest skierowany taki datagram. Zachodzi więc potrzeba rozszerzenia zestawu protokołów o mechanizm, który pozwoli rozróżniać adresy w obrębie pojedynczego komputera. Adresowanie wprost do konkretnego procesu z wielu powodów nie byłoby dobrym rozwiązaniem; np. ponieważ procesy tworzone i likwidowane są dynamicznie, nadawca ma więc zbyt mało informacji aby wskazać proces na innej maszynie, przeładowanie systemu operacyjnego powoduje zmianę wszystkich procesów itp. W miejsce tego wprowadzono abstrakcyjne punkty docelowe zwane portami protokołów. Każdy port jest identyfikowany za pomocą dodatniej liczby całkowitej. Lokalny system operacyjny zapewnia procesom określenie dostępu do portów. Nadawca musi znać adres IP odbiorcy i numer docelowego portu protokołu na maszynie odbiorcy, komunikat musi ponadto zawierać numer portu nadawcy tak aby proces odbierający komunikat mógł wysłać odpowiedź do nadawcy.
  

Protokół UDP

• 8-bitowe pole TYP komunikatu identyfikuje komunikat 
• 8-bitowe pole KOD daje dalsze informacje na temat rodzaju komunikatu, 
• Pole SUMA KONTROLNA (obliczane podobnie jak suma IP, ale suma kontrolna ICMP odnosi się tylko do komunikatu ICMP). 

Format komunikatów UDP

• Pola PORT NADAWCY i PORT ODBIORCY zawierają 16-bitowe numery portów UDP używane do odnajdywania procesów oczekujących na dany datagram. Pole PORT NADAWCY jest opcjonalne. 
• Pole DŁUGOŚĆ zawiera wartość odpowiadającą liczbie bajtów datagramu UDP wliczając nagłówek i dane. Minimalna więc wartość tego pola wynosi więc 8, czyli jest długością samego nagłówka. 
• Pole SUMA KONTROLNA jest opcjonalne. Ponieważ jednak IP nie wylicza sum kontrolnych dla danych, suma kontrolna UDP jest jedyną gwarancją, że dane nie zostały uszkodzone. 
  

Porty i połączenia

• Protokół TCP umożliwia wielu działającym na jednej maszynie programom użytkowym jednoczesne komunikowanie się oraz rozdziela między programy użytkowe przybywające pakiety TCP. Podobnie jak UDP, TCP używa numerów portów protokołu do identyfikacji w ramach maszyny końcowego odbiorcy. Każdy z portów ma przypisaną małą liczbę całkowitą, która jest używana do jego identyfikacji. Porty TCP są jednak bardziej złożone, gdyż dany numer nie odpowiada bezpośrednio pojedynczemu obiektowi. TCP działa wykorzystując połączenia, w których obiektami są obwody wirtualne a nie poszczególne porty. Tak więc podstawowym pojęciem TCP jest pojęcie połączenia, a nie portu. Połączenia są identyfikowane przez parę punktów końcowych. TCP definiuje punkt końcowy jako parę liczb całkowitych (węzeł, port), gdzie węzeł oznacza adres IP węzła, a port jest portem TCP w tym węźle. Np. punkt końcowy (128.10.2.3, 25) oznacza port 25 maszyny o adresie IP 128.10.2.3. W efekcie może istnieć połączenie np. pomiędzy: (18.26.0.36, 1069) oraz (128.10.2.3, 25), w tym samym czasie może też istnieć (128.9.0.32, 1184) oraz (128.10.2.3, 25). Zwróćmy uwagę, że w związku z tym, że TCP identyfikuje połączenie za pomocą pary punktów końcowych, dany numer portu może być przypisany do wielu połączeń na danej maszynie. 

Konfiguracja w TCP/IP w Unix-ie

• Konfiguracja większości wersji systemu UNIX, opiera się na kilku plikach konfiguracyjnych wymienionych w tabeli. W niektórych implementacjach pliki mogą się różnić nazwami, lecz ich znaczenie pozostaje takie samo. Wymienione pliki są plikami tekstowymi, więc do ich modyfikacji potrzebny jest dowolny edytor tekstowy, operujący w czystym kodzie ASCII.Datagram UDP jest przed wysłaniem w sieć, w znany nam już sposób, kapsułkowany w datagram IP. Nagłówek IP identyfikuje maszynę źródłową i docelową, UDP - identyfikuje porty nadawcy i odbiorcy. U odbiorcy pakiet dociera do najniższej warstwy oprogramowania sieciowego i wędruje ku coraz wyższym warstwom. Każda z nich usuwa jeden nagłówek, oczekujący proces otrzymuje więc komunikat bez nagłówków. Zwróćmy uwagę, że datagram UDP otrzymany od IP na maszynie docelowej jest identyczny z tym, który UDP przekazało do IP na maszynie źródłowej. 

Multipleksowanie i demultipleksowanie

• Protokoły komunikacyjne wykorzystują metody multipleksowania i demultipleksowania na poziomach wszystkich warstw. Przy wysyłaniu komputer nadawcy dołącza do danych dodatkowe bity, które wskazują typ komunikatu, program, który go nadał oraz używane protokoły. Wszystkie komunikaty są umieszczane w przeznaczonych do przesyłania ramkach sieciowych i łączone w strumień pakietów. U odbiorcy zaś te informacje są używane do sterowania przetwarzaniem. Multipleksowanie i demultipleksowanie pojawia się w prawie wszystkich warstwach protokołów. Przykładowo, gdy interfejs sieciowy zdemultipleksuje ramki i prześle te z nich, które zawierają datagramy IP do modułu IP, oprogramowanie IP wydobędzie z nich datagramy i dalej je zdemultipleksuje w warstwie IP. Aby zdecydować, w jaki sposób obsłużyć datagram, oprogramowanie sprawdza nagłówek datagramu i wybiera na podstawie typu datagramu odpowiednie procedury. 

Transsmision control protocol

• Do tej pory zajmowaliśmy się usługami zawodnego dostarczania pakietów, bez użycia połączenia, co stanowi podstawę protokołu IP. IP nie troszczy się tak naprawdę o dostarczenie datagramu do adresata, lecz w przypadku odrzucenia datagramu sygnalizuje ten fakt jako błąd maszynie-nadawcy i uznaje sprawę za załatwioną. Używanie zawodnego dostarczania bez użycia połączenia do przesyłania dużych porcji danych jest więc nużące i wymaga od programistów, aby wbudowywali do każdego programu użytkowego wykrywanie i korekcję błędów. Teraz zajmiemy się przesyłaniem niezawodnymi strumieniami TCP (ang. Transmission Control Protocol), które istotnie zwiększa funkcjonalność omawianych do tej pory protokołów, biorąc odpowiedzialność za wiarygodne dostarczenie datagramu. Okupione jest to jednak skomplikowaniem protokołu. Protokół TCP będąc drugą najważniejszą usługą w sieci, wraz z IP dał nazwę całej rodzinie protokołów TCP/IP. Pomimo związku z protokołem IP - TCP jest protokołem w pełni niezależnym i może zostać zaadaptowany do wykorzystania z innymi systemami dostarczania. Możliwe jest używanie go zarówno w pojedynczej sieci takiej jak ethernet jak i w skomplikowanej intersieci. 

Własności usługi niezawodnego dostarczania

• TCP organizuje dwukierunkową współpracę między warstwą IP, a warstwami wyższymi, uwzględniając przy tym wszystkie aspekty priorytetów i bezpieczeństwa. Musi prawidłowo obsłużyć niespodziewane zakończenie aplikacji, do której właśnie wędruje datagram, musi również bezpiecznie izolować warstwy wyższe - w szczególności aplikacje użytkownika - od skutków awarii w warstwie protokołu IP. Scentralizowanie wszystkich tych aspektów w jednej warstwie umożliwia znaczną oszczędność nakładów na projektowanie oprogramowania. TCP rezyduje w modelu warstwowym powyżej warstwy IP. Warstwa ta jest jednak obecna tylko w tych węzłach sieci, w których odbywa się rzeczywiste przetwarzanie datagramów przez aplikacje, tak więc nie posiadają warstwy TCP na przykład routery, gdyż warstwy powyżej IP nie miałyby tam nic do roboty. 

Kanał wirtualny TCP

• Rozpatrując TCP z punktu widzenia funkcjonalności można potraktować jego pracę jako ustanowienie kanału wirtualnego realizującego komunikację między "końcówkami" - tak wygląda to z punktu widzenia aplikacji użytkownika. Rzeczywisty przepływ oczywiście odbywa się poprzez warstwę IP i warstwy niższe. Aby zagwarantować, że dane przesyłane z jednej maszyny do drugiej nie są ani tracone, ani duplikowane używa się podstawowej metody znanej jako pozytywne potwierdzanie z retransmisją. Metoda ta wymaga, aby odbiorca komunikował się z nadawcą, wysyłając mu w momencie otrzymania danych komunikat potwierdzenia (ACK). Nadawca zapisuje sobie informację o każdym wysłanym pakiecie i przed wysłaniem następnego czeka na potwierdzenie. Oprócz tego nadawca uruchamia zegar w momencie wysyłania pakietu i wysyła ten pakiet ponownie, gdy minie odpowiedni czas, a potwierdzenie nie nadejdzie. 
  

Protokół Ethernet

• Technika, w której zawarte są standardy wykorzystywane w budowie głównie lokalnych sieci komputerowych. Obejmuje ona specyfikację przewodów oraz przesyłanych nimi sygnałów. Ethernet opisuje również format ramek i protokoły z dwóch najniższych warstw Modelu OSI. Jego specyfikacja została podana w standardzie IEEE 802. Ethernet jest najpopularniejszym standardem w sieciach lokalnych. Inne wykorzystywane specyfikacje to Token Ring, FDDI czy ARCNET. Ethernet został opracowany przez Roberta Metcalfe'a w Xerox PARC czyli ośrodku badawczym firmy Xerox i opublikowany w roku 1976. Bazuje na idei węzłów podłączonych do wspólnego medium i wysyłających i odbierających za jego pomocą specjalne komunikaty (ramki). Wszystkie węzły posiadają niepowtarzalny adres MAC. 

Klasyczne sieci Ethernet mają cztery cechy wspólne, są to:

• Parametry czasowe, 
• Format ramki, 
• Proces transmisji,
• Podstawowe reguły obowiązujące przy ich projektowaniu, 
   

Istnieją 4 standardy ramek: 

• IEEE 802.x LLC, 
• IEEE 802.g LLC, 
• Ethernet wersja 2 (Ethernet II) - zwana też ramką DIX od firm DEC, Intel i Xerox, które opracowały wspólnie ten typ ramki i opublikowały w 1978. Jest ona w tej chwili najczęściej stosowana, 
• Ethernet wersja 1 - już nieużywana,

Ramki różnią się pomiędzy sobą długościami nagłówków, maksymalną długością ramki (MTU) i innymi szczegółami. Różne typy ramek mogą jednocześnie korzystać z tej samej sieci. Budowa ramki składa się z: 

• Preambuła - składająca się z 7 bajtów złożonych z naprzemiennych jedynek i zer: 10101010101010101010101010101010101010101010101010101010 
• SFD - (ang. start frame delimiter), czyli znacznik początkowy ramki w postaci sekwencji 8 bitów (1 bajt): 10101011 
• Adres MAC odbiorcy (6 bajtów) 
• Adres MAC nadawcy (6 bajtów) 
• Typ (2 bajty) - jeżeli wartość jest równa lub większa od 1536 (w zapisie szesnastkowym 0x0600), to określa typ protokołu który jest używany, jeżeli mniejsza to oznacza długość danych w ramce 
• Dane (46 - 1500 bajtów) - jeżeli dane mniejsze niż 46 bajtów, to uzupełniane są zerami, suma kontrolna (4 bajty) CRC 

  POWRÓT DO STRONY GŁÓWNEJ